home *** CD-ROM | disk | FTP | other *** search
-
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by Dave O'Leary/SURAnet
-
- UCP Minutes
-
- We started by discussing the issue of funding for the activity that is
- being proposed in the draft RFC. We decided that the focus of the group
- should be only on the definition of the inter-NOC protocol and to handle
- issues of multi-NOC coordination, with the goal being the tracking of
- complaints rather than tracking problems. Tracking of complaints
- provides accountability information for the funding agencies. We then
- read through the current version of the RFC, section by section, and
- discussed needed changes:
-
- NSC's:
-
- The issue of NOC certification needs to be clarified, and a mechanism
- for maintaining the ``phonebook'' of NSC's must be decided upon,
- although these tasks are outside the scope of this document. It is
- clear that certification and an entry in the phonebook are a one-to-one
- correspondence.
-
- Clear job descriptions for NSC's, the ``phone book registrar'', etc.,
- are needed, but again, should not be part of this document.
-
- Holes in the phonebook are a problem. We cannot set enforcement
- policies for implementation of the ideas proposed in this document, but
- with an incomplete phonebook there may be situations where a ticket is
- opened but the entity responsible for fixing the problem is not a
- registered NSC and does not/cannot accept the ticket.
-
- Because of these potential holes in the book, particular organizations
- are very exposed in the initial system, as they receive many calls, and
- are forced to open tickets for each complaint, however there may be no
- means for them to resolve the problem or to pass it off to the
- responsible entity.
-
- An 800 number NSC Referral service should exist, i.e., ``I have this
- problem, who do I call?'' - somebody to look in the phonebook for those
- users that don't have a copy. Those listed in the phonebook must get a
- copy of the phone book. The User Services Working Group Ombudsman may
- be able to serve in this role.
-
- We discussed the possibility of ``You aren't our customer'' answers to
-
- 1
-
-
-
-
-
-
- user calls. The RFC explicitly disallows this, and it was noted that
- this restriction could be relaxed in the presence of a national user
- ombudsman.
-
- Next we discussed the idea of ``entitlement'' - is every user promised
- ideal service? We concluded that every user has a right to be made
- aware of and expect the level of service he is willing to subscribe to.
- It was noted that there are some fundamental problems from expectations
- of those people who are not actually directly paying for any service,
- i.e., a graduate student at a large university doesn't have too much say
- as to the university network connection purchasing decisions.
-
- It was decided that an NSC can refer a user to another ticket and refer
- the user to the resolution of that ticket, i.e., clustering of several
- user complaints under one actual set of ticket transactions.
-
- We then discussed mechanisms for sharing internal ticket information
- between NOCs. Use of a common archiving mail list and the Internet
- Rover were proposed as two possible solutions. Vikas, Dale Johnson, Tim
- Salo, Tom Easterday, Dan Long and Dave O'Leary volunteered to start work
- on this via a mailing list.
-
- Ticket Processing
-
- It was decided that a NOC could refer a user after it had transferred
- responsibility for a ticket, i.e., ``We don't have information about
- that ticket anymore, please call Other NSC at 555-1234''.
-
- We discussed problems with unregistered NSC's, particularly complaints
- that are caused by software vendor's bugs. We discussed our role as an
- enforcement agent with software vendors, i.e., tracking the number of
- vendor X problems that are currently holding open tickets in the system.
-
- Ticket Support Centers
-
- We decided that although the three functions are essentially autonomous,
- they will probably reside within the same entity, although they do not
- have to.
-
- Dialogs
-
- Multiple User dialogs can map into one Operations dialog, and multiple
- Operations dialogs can map into one Engineering dialog. Meta dialogs
- can be associated anywhere into the hierarchy. The goal of the system
- is closure with the user, not closure of operational problems. It was
- noted that ``dead'' tickets could exist, where nobody really cares about
-
- 2
-
-
-
-
-
-
- the resolution, and that a mechanism for tracking chronic problems is
- important. Explicit closure with the user is required, unless the user
- waives the right to this explicit closure.
-
- Individual NOC ticket design is not within the scope of the group, and
- it was recognized that significant post-processing of tickets will have
- to occur in many cases. We started to look at individual problems and
- how a typical ticket would be tracked through this system. It was
- decided that it is okay to tell the user the status of engineering
- problems.
-
- We discussed the case of unreasonable user demands - those who are never
- satisfied and those who generate many repetitive queries.
-
- The problems that we are trying to solve with the system:
-
-
- 1. Complaints that are dropped between NOCs.
- 2. NOCs that ``lose'' tickets - i.e., quality control on other NOCs.
- - expected level of service is an issue here.
- 3. Communication on complaints for knowledge of operational and
- engineering situations.
- 4. Statistics on complaints.
- 5. Accountability
-
-
- A different agenda is being addressed by each of the four dialogs, so
- the ticketing system must address these four issues. Individual tickets
- may not have discussion in each of the four dialogs.
-
- The introduction to the dialog section should preclude the possibility
- of separation of dialogs, i.e., each discussion should be taken in the
- context in which it was generated.
-
- Regarding the final status of tickets, it was re-emphasized that tickets
- are closed in the User dialog. Engineering problems are resolved by the
- responsible NSC, possibly at a different time from the closure with the
- user. Tickets can be closed with unhappy users, i.e., if an engineering
- problem exists with no solution in the foreseeable future. A question
- is how to measure the relative satisfaction before and after the
- problem.
-
- Access to Tickets
-
- An NSC can access any ticket in which it is referenced. Unregistered
- entities (i.e., other NOCs) can also access tickets in which they are
-
- 3
-
-
-
-
-
-
- referenced. It may be appropriate to provide the user more data than is
- formally required.
-
- Ticket Tracking System
-
- It Holds:
-
-
- o Ticket Numbers
- o Ticket Status (for each dialog)
- o Parties Involved with Ticket
- o A Recent Copy of the Ticket (much discussion was generated)
-
-
- Privacy Issues:
-
-
- o What do the funding agencies think about this?
- o What about disinterested parties with complaints from users?
- o What about the persons involved?
-
-
- At the end, Matt volunteered to work on the introduction to the document
- to clarify the focus in two ways:
-
-
- 1. It is specifically addressing user complaints.
- 2. It is addressing inter-NOC problem resolution.
-
-
- Following the group meetings, a document editing session was held with
- Matt Mathis, Dan Long, Gene Hastings, and Dave O'Leary. A new draft
- will be available soon and inserted into the informational
- internet-drafts track.
-
- Attendees
-
- Vikas Aggarwal vikas@JVNC.net
- Ronald Broersma ron@nosc.mil
- Robert Collet /pn=robert.d.collet/o=us.sprint/admd=telemail/c=us/@sprint.com
- Tom Easterday tom@nisca.ircc.ohio-state.edu
- Jeff Forys forys@cs.utah.edu
- Vince Fuller vaf@Standford.EDU
- Jack Hahn hahn@umd5.umd.edu
- Eugene Hastings hastings@psc.edu
- Dale Johnson dsj@merit.edu
-
- 4
-
-
-
-
-
-
- Dan Jordt danj@cac.washington.edu
- Darren Kinley kinley@crim.ca
- Walter Lazear lazear@gateway.mitre.org
- Daniel Long long@bbn.com
- Matt Mathis mathis@pele.psc.edu
- Judy Messing messing@gateway.mitre.org
- Donald Morris morris@ucar.edu
- David O'Leary oleary@noc.sura.net
- Mark Oros oros@nmc.cit.cornell.edu
- Timothy Salo tjs@msc.edu
- Tom Sandoski tom@concert.net
- Kannan Varadhan kannan@oar.net
-
-
-
- 5
-